1. Field of the Invention
This invention relates to equipment management systems.
2. Related Art
An equipment management system comprises, in general, one or more pieces of equipment which are monitored and controlled by an equipment manager via an equipment controller.
A particular example of such a system is a network management system in which the equipment comprises interconnected network elements of a telecommunications network controlled by a network element manager. The equipment manager comprises a network manager through which the functioning of the network can be monitored, and instructions can be generated to control the network as required via the network element manager. In general the network will be composed of several different types of network elements, for example modems and multiplexers.
The equipment manager and equipment controller are arranged to communicate using text messages having a plurality of fields according to one protocol whilst the equipment controller and equipment communicate according to a different protocol. In general, for different equipment and equipment controllers, different protocols are used.
If the network manager is not configured to be able to interface with the one, or many, different protocols from the network element managers, it becomes necessary to use several, independent, network managers. There are several disadvantages with such systems arising from the fact that the different network managers do not intercommunicate: it may not be possible, for example, to identify a fault occurring on one part of the network as the cause of problems reported to different network managers. Thus a link may fail which will cause other alarms to be raised to other network managers but it may not be possible to identify the causal connection between these related problems.
In order to avoid such intercommunication difficulties between network managers, it is desirable to adopt an integrated network management approach in which the network management system has a single integrated network manager which produces messages according to a particular protocol but which is able to communicate with all the diverse network element managers.
This integration may be achieved by translation of the "equipment" protocol to a single "management" protocol, either in the equipment controller (for example a network element manager) or in the equipment manager (for example a network manager).
One network management protocol which is being widely adopted is that which conforms to the specifications developed by the Open Systems Interconnection (OSI) Network Management Forum (NMF) which is an international consortium of some 70 member companies worldwide established in July 1988. The object of defining an OSI-NMF standard is to encourage vendors worldwide towards making their proprietary element managers conform to the specification thereby allowing the ready implementation of an integrated network management system.
Such standardisation cannot occur immediately as it needs time for individual equipment manufacturers to modify their existing equipment to the agreed standard, but is a standard to which it is hoped the different vendors will migrate in the course of time. However, even if manufacturers do move to a standard it is expected that not all will use the full functionality that the protocol can provide but will implement some subset of it.
In the absence of all equipment element managers conforming to the OSI-NMF protocol, or some other standard which may be agreed, it is necessary to provide translations from the non-standard protocols adopted by various equipments to an equivalent message in the OSI protocol and vice versa.
A computer implemented interface between the equipment controller and equipment manager is known to be used for translating an original text message in one protocol to a translated text message in the other protocol thereby providing two-way communication between the controller and manager. Such a known interface provides a complete translation process by maintaining its own internal database of translation rules for the non-conformant element managers. It provides the ability to receive management data from a proprietary element manager thus obviating the need for that manufacturer to convert their element manager to OSI-NMF compliance in order to be used in an integrated management system. There are however disadvantages associated with the prior art approaches to providing these translations.
The approach used to date is to take the proprietary message, break it down into its component parts and then do a tree search to see to which of the allowable combinations of components a particular message corresponds. This tree search is then used to access the database to determine the equivalent OSI-NMF conformant message corresponding to the proprietary protocol message. If the number of distinct, proprietary messages is large then the tree search can have very many nodes and require a very large database to be able to supply all the equivalent translations. The technical difficulty of implementing such an interface has led in some cases to system designs providing only partial translations from the proprietary protocol to the OSI-NMF protocol resulting in less than optimum functionality.
Further, the translation to be carried out can be dependent on the state of the system which therefore needs to be taken into account at some stage of the translation process. In prior art systems this requires access to a data base modelling the system.
A further disadvantage is that such interfaces require a great deal of software support. The database has to be modified as the network is changed so that the proprietary messages are translated correctly which requires a great deal of time and effort. This prior art technique also produces a bottleneck as different messages are received requiring successive accesses to the database in order to carry out the translation. Such techniques require large amounts of data storage and repeated accesses to a database which slows down the translation process thereby introducing delays into the time taken for a network to respond to instructions input via a network manager and for a network manager to report, for example, faults and alarms generated by a network when a fault occurs.